feat(txm): added txm callbacks and promises when tx status change#719
Conversation
Deploying happychain with
|
| Latest commit: |
e5b67a8
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://9b389e5f.happychain.pages.dev |
| Branch Preview URL: | https://gabriel-txm-transaction-call.happychain.pages.dev |
This stack of pull requests is managed by Graphite. Learn more about stacking. |
HAPPY-496 Implement a mechanism to easily allow TXM users to be notified when a transaction changes status
Currently, it's a bit tedious for a TXM user to know when a transaction has finished. This is because the hooks are general for all transactions, not for a specific one. It might be a good idea to implement a method in the One possible approach is to provide a callback when creating the transaction, and once the transaction is included in the TXM, collect that callback and notify the user when the transaction is updated. The usage could be: |
2f78932 to
3f8de75
Compare
packages/txm/lib/Transaction.ts
Outdated
| this.waitingPromises = [] | ||
| } | ||
|
|
||
| this.callbacks[status].forEach((callback) => callback(this)) |
There was a problem hiding this comment.
what happens if the callback throws?
packages/txm/lib/Transaction.ts
Outdated
| this.callbacks[status].push(callback) | ||
| } | ||
|
|
||
| waitForFinalization(timeout?: number): Promise<Result<Transaction, Error>> { |
There was a problem hiding this comment.
nit: not immediately obvious this is milliseconds, maybe rename to timeoutMs or document/comment.
packages/txm/test/txm.test.ts
Outdated
|
|
||
| test("Use transaction.waitForFinalization() to wait for a transaction to be finalized", async () => { | ||
| let promiseResolved = false | ||
| const transaction = await createCounterTransaction() |
There was a problem hiding this comment.
not urgent but createCounterTransaction should not be async
packages/txm/lib/Transaction.ts
Outdated
| * Stores promises that wait for the transaction to be finalized. | ||
| * These promises are resolved when the transaction status changes to a finalized state. | ||
| */ | ||
| private waitingPromises: ((transaction: Result<Transaction, Error>) => void)[] |
There was a problem hiding this comment.
nit: rename to waitingFinalizedPromises
There was a problem hiding this comment.
Could even be finalizedPromiseResolvers
| let promiseResolved = false | ||
| const transaction = await createCounterTransaction() | ||
|
|
||
| transaction.waitForFinalization().then((result) => { |
There was a problem hiding this comment.
can we add a timeout test to check that that functionality works as intended?
3f8de75 to
3bf00b1
Compare
packages/txm/lib/Transaction.ts
Outdated
| this.callbacks = Object.values(TransactionStatus).reduce( | ||
| (acc, status) => { | ||
| acc[status] = [] | ||
| return acc | ||
| }, | ||
| {} as Record<TransactionStatus, ((transaction: Transaction) => void)[]>, |
There was a problem hiding this comment.
| this.callbacks = Object.values(TransactionStatus).reduce( | |
| (acc, status) => { | |
| acc[status] = [] | |
| return acc | |
| }, | |
| {} as Record<TransactionStatus, ((transaction: Transaction) => void)[]>, | |
| this.callbacks = {} as Record<TransactionStatus, ((transaction: Transaction) => void)[]> | |
| Object.values(TransactionStatus).forEach((status) => { this.callbacks[status] = [] }) |
There was a problem hiding this comment.
I ran stats on the repo the other day and this is the biggest file in it :D
Not important, but we can probably consider splitting it up sometime in the future.
There was a problem hiding this comment.
3bf00b1 to
40a224e
Compare

Linked Issues
Description
Implemented a simple mechanism to wait for transaction finalization in the transaction manager
Toggle Checklist
Checklist
Basics
norswap/build-system-caching).Reminder: PR review guidelines
Correctness
testnet, mainnet, standalone wallet, ...).
< INDICATE BROWSER, DEMO APP & OTHER ENV DETAILS USED FOR TESTING HERE >
< INDICATE TESTED SCENARIOS (USER INTERFACE INTERACTION, CODE FLOWS) HERE >
and have updated the code & comments accordingly.
Architecture & Documentation
(2) commenting these boundaries correctly, (3) adding inline comments for context when needed.
Public APIS and meaningful (non-local) internal APIs are properly documented in code comments.
in a Markdown document.
make changesetforbreaking and meaningful changes in packages (not required for cleanups & refactors).